Embedded systems are used in a variety of today's electromechanical systems. These systems are often configured to perform one or more specialized tasks associated with the system in which they are deployed. In many cases, these embedded systems perform centralized operational and control functions associated with a larger system, functioning as the “brain” of the system. For example, an embedded system may include an electronic control unit (ECU) programmed to monitor and/or control particular aspects and/or operations associated with the device in which it operates. Embedded systems are often highly specialized and critical to the performance of the systems in which they are implemented.
In order to minimize manufacturing and repair costs, generic embedded systems were developed that are compatible with a variety of different hardware. Once installed in a device, these generic systems may be customized using functional, processor-executable software loaded into a memory device associated with the system. This functional software may contain instructions for controlling virtually every operation associated with the device. By customizing operations of each embedded system at the software level, the same hardware system may be employed in variety of applications, allowing for mass-production of the generic hardware. Further, because the functionality of the system is defined almost exclusively in software, updates, modifications, and upgrades may be made to the system without necessitating replacement of the system hardware, thereby reducing repair and upgrade costs.
Because software for embedded systems may define virtually all functional aspects associated with the system, the design of software for these systems may be complicated, time intensive, and require highly specialized knowledge of software code. For example, a block of software that defines a simple dataflow function related to one component associated with a larger system may comprise several hundred lines of code. This block may be combined with other blocks of code to define operations associated with an entire system, from monitoring and control operations to data transmission and warning system operations. In all, software associated with an engine controller may comprise hundreds of thousands of lines of code, including hundreds of individual software blocks.
In an attempt to simplify the software design for embedded systems, some automated design tools have been developed. These design tools typically allow users to generate software by providing a design environment where data models corresponding to small blocks of software code may be graphically assembled to create a functional “map” of a desired software application. These small blocks (referred herein as data elements) may be interconnected with other data elements to form a software block, which may define higher level functions defined by the one or more data elements included in the block. This software block may be executed by a software design tool to generate software code associated with the graphical design. These software blocks may be stored and reused in future designs.
Each data element may be represented as either an variant data element (referred to as a signal) or an invariant data element (referred to as a parameter). In a typical design environment signals may be routed and/or interconnected with other data elements. Parameters, on the other hand, are typically manually defined for a particular data element and are generally not configured to be routed or interconnected. As a result, if the same parameter is being used in multiple instances, users may be required to manually define the parameter in each instance. Furthermore, as a practical matter, because signals are generally interconnected in a graphical design tool using lines (or wire) representations while parameters may only include parameter names or value designations, dataflow tracking and identification may be significantly easier for signal-type data elements.
In order to capitalize on the design flexibility and ease of use of signal-type data elements, many software design tools define all data elements, variant and invariant alike, as signals. However, implementing software functions associated with signal data elements (i.e., variable data elements) in hardware may have several disadvantages. For example, because of the variant nature of signals (i.e., the ability to take on multiple values or functions, depending on certain impulses that they receive), writable memory and additional processing capacity may be required, as operations on variant data may be substantially more complicated than operations on invariant (i.e., constant) data. As a result, complex and expensive hardware may be required to accommodate the writable memory and increased processing capabilities that may be necessitated by signal-type data element designation. Accordingly, it may be advantageous to provide certain signal-type design capabilities without necessarily increasing the complexity or expense of the embedded system hardware. Thus, to maximize design flexibility, while minimizing hardware costs associated with the software implementation, a software design tool with reusable data elements that enables users to take advantage of both signal-type and parameter-type data treatment, may be required.
At least one system has been developed that allows users to select certain configurations associated with software design blocks. For example, U.S. Patent Publication No. 2005/0278162 (“the '162 publication”) to Ciolfi et al. provides a software design environment that includes “variant” software configuration blocks. These blocks allow users to switch between various input sources, output destinations, and dataflow paths associated with the system model, which may allow users to analyze multiple software blocks in a single design environment.
Although the system of the '162 publication provides a user configurable software environment, it may be inadequate in certain situations. For example, the system of the '162 publication only allows user users to switch between multiple input and output sources in order to simulate several software models during different iterations of the model. It does not, however, provide a system for designing embedded software using data elements that can be configured as either variant or invariant at any time. As a result, in cases where a user requires a single data element whose variability is configurable at software run-time, users may be required to develop separate data elements, one for supporting variant data and the other for supporting invariant data. In addition to being time consuming, this multiple-design method may be inefficient.
The presently disclosed data elements with interchangeable signal/parameter behavior control is directed toward overcoming one or more of the problems set forth above.